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(54) Vehicle mode manager 

(57) A vehicle mode manager manages vehicle 
state information. The vehicle mode manager includes 
a code module that registers an appiicatlon program 
with the vehicle mode manager. Registering Indicates 
the application program will be notified of vehicle state 
changes. Also included in the vehicle mode manager Is 
a code module that receives vehicle status infomnation. 
and a code module that determines a vehicle state 
based on both the vehicle status infonnatlon and a cur- 
rent vehicle state, in addition, a privileged application or 
another manager can also set the vehicle state. The ve- 
hicle mode manager also Includes a code module that 
provides the vehicle state to an'application program. In 
this manner, the application program can react to the 
vehicle state information in a predefined manner. 
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Description 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

[0001] This invention relates generally to telematic 
devices, and more particularly to a vehicle mode man- 
ager capable of managing the state of a vehicle. 

2. Description of the Related Art 

[0002] The electronic content and sophistication of 
automotive designs has grown marl^edly. Microproces- 
sors are prevalent in a growing anray of automotive en- 
tertainment, safety, and control functions. Consequent- 
ly, this electronic content is playing an increasing role in 
the sales and revenues of the automakers. The features 
provided by the electronic content include audio sys- 
tems, vehicle stability control, driver activated power 
train controls, adaptive cruise control, route mapping, 
collision warning systems, security systems, etc. The 
significant increase of the electronic content of land 
based vehicles has concomitantly occurred with the ex- 
plosive growth of the Internet and the associated data 
driven applications supplied through mobile applica- 
tions. 

[0003] Telematics, a broad temi that refers to vehicle- 
based wireless communication systems and informa- 
tion services, promises to combine vehicle safety, en- 
tertainment, and convenience features through wireless 
access to distributed networks, such as the Internet. 
Telematics offers the promise to move away from the 
hardware-centric model from audio and vehicle control 
systems that are built into devices that are custom de- 
signed for each vehicle, to infotainment delivered by 
plug-and-play hardware whose functionality can be up- 
graded through software loads or simple module re- 
placement. Furthermore, new revenue streams will be 
opened up to automobile manufacturers and service 
providers through the products and services made avail- 
able through telematics. 

[0004] However, cun-ent telematic systems interact 
with the state of a vehicle on a very limited basis. For 
example, a telematic system may Inform the driver that 
they are low on fuel, or have a low tire pressure. But 
cun-ent telematic systems generally do not provide ve- 
hicle state information to intelligent telematic systems, 
which are capable of providing additional services 
based on the vehicle state. 

[0005] In view of the forgoing, there is a need for sys- 
tems and methods to manage the vehicle state. The sys- 
tems and methods should obtain vehicle state infonna- 
tion and manage that information by providing the state 
information to intelligent telematic systems capable of 
providing additional services based on the state infor- 
mation. 



SUMMARY OF THE INVENTION 

[0006] Broadly speaking, the present Invention fills 
these needs by providing a vehicle mode manager ca- 

5 pable of managing vehicle state infonmation and provid- 
ing the vehicle state information to interested application 
programs. In one embodiment, a method for providing 
vehicle state management is disclosed. Vehicle status 
information is received, and a vehicle state is deter- 

10 mined based on the received vehicle status Information. 
The vehicle state then is provided to an application pro- 
gram. In this manner, the application program can react 
to the vehicle state information in a predefined manner. 
[0007] A computer program embodied on a computer 

15 readable medium for providing vehicle state manage- 
ment is disclosed In an additional embodiment of the 
present invention. The computer program includes a 
code segment that receives vehicle status information, 
and a code segment that determines a vehicle state 

20 based on the vehicle status infomiation. A further code 
segment is included that provides the vehicle state to 
an application program. As above, the application pro- 
gram can react to the vehicle state information in a pre- 
defined manner. 

25 [0008] In a further embodiment, a vehicle mode man- 
ager is disclosed for providing vehicle state manage- 
ment. The vehicle mode manager includes a code mod- 
ule that registers an application program with the vehicle 
mode manager. In some embodiments, the code mod- 

30 ule can register the application program with other soft- 
ware layers related to the vehicle mode manager, such 
as an open services gateway initiative (OSGI) layer. 
Registering indicates the application program will be no- 
tified of vehicle state changes. Also included in the ve- 

35 hide mode manager is a code module that receives ve- 
hicle status infomiation, and a code module that deter- 
mines a vehicle state based on both the vehicle status 
information and a current vehicle state. In addition, the 
vehicle mode manager includes a code module that pro- 

40 vides the vehicle state to an application program. In this 
manner, the application program can react to the vehicle 
state infomiation in a predefined manner. Other aspects 
and advantages of the invention will become apparent 
from the following detailed description, taken in conjunc- 

45 tton with the accompanying drawings, illustrating by way 
of example the principles of the Invention. 

BRIEF DESCRIPTION OF THE DRAWINGS 

50 [0009] The Invention, together with further advantag- 
es thereof, may best be understood by reference to the 
following description taken in conjunction with the ac- 
companying drawings. 

55 Figure 1 is a high level schematic overview of an 
automotive telematics system in accordance with 
one embodiment of the Invention; 
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Figure 2 is a schematic diagram of a telematics cli- 
ent communicating through a wireless network with 
a telematics server in accordance with one embod- 
iment of the invention; 

5 

Figure 3 is a three dimensional pictorial represen- 
tation of a telematics client reference implementa- 
tion of the client side stack of Figure 2 in accordance 
with one embodiment of the invention; 

10 

Figure 4 is a block diagram showing an in-vehicle 
vehicle mode management system, in accordance 
with an embodiment of the present Invention; 

Figure 5 is a state diagram showing exemplary ve- ^5 
hide state relationships based on vehicle status in- 
formation, in accordance with an embodiment of the 
present invention; and 

Figure 6 is a flowchart showing a method for pro- 20 
viding vehicle state management, in accordance 
with an embodiment of the present invention. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 25 

[0010] An invention is disclosed for a vehicle mode 
manager. In the following description, numerous specif- 
ic details are set forth in order to provide a thorough un- 
derstanding of the present invention. It will be apparent, 30 
however, to one skilled in the art that the present inven- 
tion may be practiced without some or all of these spe- 
cific details. In other instances, well known process 
steps have not been described in detail in order not to 
unnecessarily obscure the present invention. 35 
[001 1] Embodiments of the present invention provide 
a mechanism for managing vehicle state information 
and providing the state information to services that can 
take appropriate action based on the state information. 
Broadly speaking, a vehicle state is a logical entity that 40 
describes various facts about a vehicle. For example, a 
normal state may indicate a situation in which a vehicle 
is turned on, and the ignition and motor are running. A 
towed state may be described as one in which the ve- 
hicle Is being towed. The vehicle mode manager of the ^5 
embodiments of the present invention obtains vehicle 
status infomnation, determines the vehicle state based 
on the vehicle status information, and notifies specific 
vehicle systems, which can take appropriate action 
based on the vehicle state, so 
[0012] Generally speaking, embodiments of the 
present invention are implanted in a client side of a 
telematics system. As will be explained in more detail 
below, the client side of a telematics system includes a 
telematics control unit (TCU) that Is incorporated into a 55 
vehicle system. In one embodiment, the TCU is associ- 
ated with a user interface (Ul) that provides a user with 
access to control options. It should be appreciated that 



4 

the user can interact with the TCU through speech rec- 
ognition, a mouse type device, touch pad or some other 
suitable mechanism which has a minimal impact on the 
driver's ability to drive. Of course, a passenger of the 
vehicle is not limited by the restrictions on the driver with 
respect to the interaction with the Ul. 
[0013] The TCU can communicate with any of the 
control systems, safety systems, entertainment sys- 
tems, information systems, etc., of the vehicle. It will be 
apparent to one skilled in the art after a careful reading 
of the present disclosure that the client side stack of the 
TCU is utilized to access a vehicle interface component 
for accessing in-vehicle devices, such as the speedom- 
eter, revolutions per minute (rpm) indicator, oil pressure, 
tire pressure, etc. Thus, client side applications sitting 
in the TCU allow for the functionality with respect to the 
vehicle systems as well as infotainment applications. 
[0014] In one embodiment, the telematics system de- 
ploys Java technology. It should be appreciated that 
Java technology's platform-independence and superior 
security model provide a cross-platfonn solution for the 
heterogeneous systems of a vehicle while maintaining 
a security architecture protecting against viruses and 
unauthorized access. Thus, the content or service pro- 
vider is insulated against the myriad of car platfomis 
while vehicle manufacturers are protected against hack- 
er threats. In addition, Java application program inter- 
faces (APIs) are available to support telematics medi- 
ums, such as speech recognition through Java Speech 
API (JSAPI), media delivery through Java Media Frame- 
work { JMF) and wireless telephony through Wireless te- 
lephony communications APIs (WTCA), etc. 
[0015] Figure 1 is a high level schematic overview of 
an automotive telematics system in accordance with 
one embodiment of the invention. A client/server archi- 
tecture relying on standards and principles of modular 
design allows for functionality of the telematics system 
to be delivered to the customer through wireless access. 
The server side includes Java provisioning server (JPS) 
106 in communication with network 104. 
[0016] In one embodiment, the client side includes 
telematics control unit (TCU) 102 contained within a 
land based vehicle 1 00. Of course, the TCU's implemen- 
tation is not limited to land based vehicles, and is equally 
applicable to boats, planes, hovercraft, space shuttles, 
etc., which are ail recipients of the technology defined 
herein. TCU 102 is enabled to communicate with net- 
work 104 through wireless access. Of course, the net- 
work 104 can be any distributed network such as the 
Internet and the wireless access protocol (WAP) can be 
any suitable protocol for providing sufficient bandwidth 
for TCU 1 02 to communicate with the network. It should 
be appreciated that the client/server architecture of Fig- 
ure 1 allows for the evolution from hard wired, self-con- 
tained components to platform based offerings relying 
on software and upgrades. Thus, a service provider con- 
trolling the JPS 106 can deliver an unbundled, open 
end-to-end solution enabling plug-and-play applica- 
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tions. For example, the service can be a tier-based serv- 
ice similar to home satellite and cable services. It will be 
apparent to one skilled In the art that an open platfonm, 
such as frameworks based on Java technology, enables 
a developer to create executable applications without s 
regard to the underlying hardware or operating system. 
[0017] Figure 2 is a schematic diagram of a telematics 
client communicating through a wireless network with a 
telematics server in accordance with one embodiment 
of the invention. A client side stack 1 1 0 Includes the nec- io 
essary layers for a client application, also referred to as 
a manager or a carlet, to be executed to provide func- 
tionality. As will be explained further below, the carlet 
has access to each layer of the client side stack 110. 
Included in client side stack 1 1 0 Is client communication is 
framework 112. Client communication framework 112 
enables communication between the client side stack 
110 and an application on server 116 through network 
114. 

[001 8] It should be appreciated that the server 1 1 6 is 20 
not limited to a wireless connection. For example, the 
server 116 can be hard-wired into network 114. One 
skilled in the art will appreciate that where server 116 
communicates through a wireless connection with net- 
work 114, the communication proceeds through server 25 
communication framework 118, With respect to an em- 
bodiment where server 116 is hardwired to network 114, 
the server can communicate with network 114 through 
a network portal (e.g., the Internet) rather than server 
communication framework 118. Additionally, network 30 
114 can be any suitable distributed network, such as the 
Internet, a local area network (LAN), metropolitan area 
network (MAN), wide area network (WAN), etc. 
[0019] Figure 3 is a three dimensional pictorial repre- 
sentation of a telematics client implementation of the c!i- 35 
ent side stack of Figure 2 In accordance with one em- 
bodiment of the Invention. Client side implementation 
121 includes hardware layer 120 of the client, which can 
include an embedded board containing a telematics 
control unit (TCU). As mentioned above, with reference ^0 
to Figure 1, the TCU is incorporated into a land based 
vehicle. In one embodiment, the TCU is in communica- 
tion with the electronic components of a vehicle through 
a vehicle bus, or by other means. These components 
include the measurement of vehicle operating and safe- 45 
ty parameters, such as tire pressure, speed, oil pres- 
sure, engine temperature, etc., as well as information 
and entertainment components, such as audio system 
settings, Internet access, environmental control within 
the cabin of the vehicle, seat positions, etc. One skilled so 
in the art will appreciate that the telematics control unit 
is capable of integrating the functionality of various 
handheld infonnation and entertainment (infotainment) 
devices, such as mobile phones, personal digital assist- 
ants (PDA), MP3 players, etc. ss 
[0020] Still refen^lng to Figure 3, an operating system 
layer 122 is above the hardware layer 120. In addition, 
a Java virtual machine (JVM) layer 124 Is above the op- 



erating system (OS) layer 122 and an open services 
gateway initiative (OSGI) layer 126 is located above the 
JVM layer 124. It should be appreciated that the stand- 
ard for JVM layer 124 can include the Java 2 Platform 
Micro Edition (J2ME), Connected Device Configuration 
(CDC), Foundation Profile, Personal Profile, or Personal 
Basis Profile. One skilled in the art will appreciate that 
J2ME Foundation Profile is a set of APIs meant for ap- 
plications running on small devices that have some type 
of network connection, while J2ME Personal Profile pro- 
vides the J2ME environment for those devices with a 
need for a high degree of Internet connectivity and web 
fidelity. 

[0021] The exemplary standards for each of the layers 
of the stack are provided on the right side of client side 
reference implementation 121 . In particular, OSGI 126a, 
J2ME 124a, OS 122a, and embedded board 120a are 
standards and to the left of the standards are examples 
of actual products that implement the standards. For ex- 
ample, OSGI 126a standard is implemented by Sun's 
Java Embedded Server (JES) 2.1 126b. J2ME 124a 
standard is implemented by Insignia's Virtual Machine 
124b, OS 122a is implemented by Wind River's Vx- 
Works real time operating system 122b, and embedded 
board 120a is an embedded personal computer based 
board such as Hitachi's SH4. It should be appreciated 
that the actual products are exemplary only and not 
meant to be limiting as any suitable product implement- 
ing the standards can be utilized. 
[0022] Carlets 132 of Figure 3, have access to each 
layer above and including OS layer 122. Application pro- 
gram interface (API) layer 130 is the layer that carlets 
use to communicate with the JTC. Service provider in- 
terface (SPI) layer 128 is a private interface that man- 
agers have among each other. One skilled in the art will 
appreciate OSGI layer 126 provides a framework upon 
which applications can run. Additional functionality over 
and above the JVM, such as lifecycle management, is 
provided by OSGI layer 126. It should be appreciated 
that the open services gateway initiative is a cross-in- 
dustry working group defining a set of open APIs for a 
service gateway for a telematics system. These APIs 
consist of a set of core framework APIs. In order to de- 
ploy services and their implementations, OSGi defines 
a packaging unit called a service bundle. A service bun- 
dle is a Java Archive (JAR) file containing a set of serv- 
ice definitions along with their corresponding Implemen- 
tation, Both infrastructure services and carlets are de- 
ployed as service bundles. Some of the functionality for 
arbitrating, controlling and managing devices and re- 
sources, e.g., speakers cell phones, etc., is provided by 
OSGI layer 126. However, one skilled in the art will ap- 
preciate that separate arbitration services may also be 
required. 

[0023] As used herein, a carlet is a Java™ applica- 
tion. For each function or task to be processed on the 
client side or between the client and server sides, a car- 
let is invoked to manage the operation. In this manner. 
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carlets can be Independently written, tested, and 
launched for use on a telematics system. By way of ex- 
ample, a carlet can be written to control or monitor the 
activity of automobile components (e.g., tires, engineoil. 
wiper activity, steering tightness, maintenance recom- 5 
mendatlons, air bag control, transmission control, en- 
gine temperature monitoring, etc.), and to control or 
monitor applications to be processed by the telematics 
control unit (TCU) and interacted with using the on- 
board automobile monitor. As such, specialized carlets io 
can be written to control the audio system, entertain- 
ment modules (e.g., such as on-line games or movies), 
voice recognition, telecommunications, email communi- 
cations (text and voice driven), etc. Accordingly, the type 
of carlets that can be written Is unlimited. *5 
[0024] As mentioned previously, embodiments of the 
present invention provide a vehicle mode manager that 
defines various states in which a vehicle can be in and 
allows vehicle systems to react to these states. Figure 
4 is a block diagram showing an in-vehlcle vehicle mode 20 
management system 400, in accordance with an em- 
bodiment of the present invention. As shown In Figure 
4, the exemplary vehicle mode management system 
400 includes a vehicle mode manager 402 executed 
within a Java telematics layer 401 . In one embodiment, 25 
the Java telematics layer 401 forms a portion of the OS- 
Gl layer described above. As mentioned above, the OS- 
Gl layer provides a framework upon which applications 
can run, and Includes additional functionality over and 
above the JVM, such as llfecycle management. In com- 30 
munication with the vehicle mode manager 402 Is a plu- 
rality of application programs, or cariets 132a-132c, 
which as described in greater detail subsequently, pro- 
vide various vehicle services based on the vehicle state 
or mode. The vehicle mode manager 402 is further in 35 
communication with a plurality of vehicle sensors 404a- 
404b. 

[0025] In operation, the vehicle mode manager 402 
defines various states in which the vehicle can be in and 
allows carlets 1 32a-1 32c and other vehicle systems to 
react to the defined states. Generally speaking, the ve- 
hicle mode manger 402 can detect, using various crite- 
ria, changes in the vehicle status. In addition, the vehicle 
status can be set by cariets 132a-132c or application 
service programs, which themselves may be executed « 
on the vehicle client or on the telematic server. Once the 
vehicle state, or mode, is defined by the vehicle mode 
manager 402. interested applications can be notified of 
the vehicle state, and take appropriate action. In one 
embodiment, interested applications are application so 
programs that are registered with the vehicle mode 
manager 402. Then, whenever the state changes, or 
when queried by a registered application program, the 
vehicle mode manager 402 can provide the vehicle state 
Infomiatlon to any registered application programs. 55 
[0026] For example, the exemplary vehicle mode 
management system 400 illustrated in Figure 4 shows 
two sensors 404a-404b in communication with the ve- 



hicle mode manager 402. In operation, the vehicle mode 
manger 402 receives vehicle status information from the 
vehicle sensors 404a-404b and uses the received vehi- 
cle status information to determine the cun^ent vehicle 
state. For example, the oil sensor 404a can provide the 
vehicle mode manager 402 with"low oil" status infomna- 
tion. The vehicle mode manger 402 then utilizes the low 
oil status information received from the oil sensor 404a, 
in conjunction with other obtained vehicle status infor- 
mation, to calculate the current vehicle state. 
[0027] The vehicle mode manager 402 can then pro- 
vide the current vehicle state to registered application 
programs. For example, based on the "low oil" status 
infomnation, the vehicle mode manager 402 may set the 
vehicle state to "check ftuids," and provide the "check 
fluids" state to the registered cariets 132a-132b. In this 
example, the oil service cartet 1 32b may react to the new 
"check fluids" state by displaying the oil level to the user, 
in addition, the tow caHet 132a and the stolen cariet 
1 32c may take no action, for example, because the serv- 
ices provide by these cariets may not be related to the 
"check fluids" state. 

[0028] As mentioned above, the current vehicle state 
can be set using cariets and/or application service pro- 
grams. For example, the user's preference information 
can be stored on the telematic server. This information 
can include, for example, the date of the vehicle's last 
oil change and the frequency of the vehicle's oil chang- 
es. Based on this user preference information, an appli- 
cation service program executing on the telematics 
server may calculate the date of the next scheduled oil 
change for the vehicle and provide that infomnation to 
the oil service carlet 132b. When the oil service cariet 
132b is notified of the next oil change, the oil service 
cariet 1 32b can set the vehicle state, for example, to the 
"check fluids" state. 

[0029] In addition, the vehicle mode manager 402 can 
utilize the curent vehicle state in conjunction with new 
vehicle status infomiation to determine the new vehicle 
state. Figure 5 is a state diagram showing exemplary 
vehicle state relationships based on vehicle status in- 
fomiation, in accordance with an embodiment of the 
present invention. Figure 5 illustrates four exemplary ve- 
hicle states, namely, Normal 500, Off 502, Towed 504, 
and Stolen 506. For example, the Normal 500 vehicle 
state can be defined as the vehicle is turned on, and the 
ignition and motor are running. The Off 502 vehicle state 
can be defined as the car is turned off and not moving. 
The Towed 504 vehicle state can be defined as the ve- 
hicle is off and moving when the vehicle alarm is off, and 
the Stolen 506 vehicle state can be defined the vehicle 
being taken away unlawfully without consent of the own- 
er. Although only four vehicle states are depicted in Fig- 
ure 5. it should be noted that any number of vehicle 
states can be defined for a particular vehicle. As de- 
scribed below, based on the cun'ent vehicle state and 
received vehicle status infonmatlon, the vehicle mode 
manger can set the new vehicle state. 
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[0030] For example, when the vehicle is currently in 
the Normal vehicle state 500. and the vehicle mode 
manager receives ''ignition off 508 vehicle status infor- 
mation, the vehicle mode manger can change the vehi- 
cle state to Off 502. Similarly, when the vehicle is cur- 5 
rently in the Off vehicle state 502, and the vehicle mode 
manager receives "ignition on" 510 vehicle status infor- 
mation, the vehicle mode manger can change the vehi- 
cle state to Normal 500. 

[0031] In another example, the vehicle may be io 

equipped with a gyroscope 404b, as shown in Figure 4. 
As will be appreciated by those skilled in the art, a gy- 
roscope 404b can be utilized to detect vehicle move- 
ment. Refenring back to Figure 5. in one embodiment, 
when the vehicle is in the Off 502 state, the vehicle mode is 
manager detects vehicle movement using the gyro- 
scope 404b. In particular, when the gyroscope 404b 
senses vehicle movement, the gyroscope 404b can pro- 
vide "car movement" status information the vehicle 
mode manager. As will be appreciated by those skilled 20 
in the art, additional criteria can be used to detenmine if 
a car is towed, for example, requiring only two wheels 
are moving. 

[0032] Hence, when the vehicle is currently in the Off 
502 state, and the vehicle mode manager receives "car 25 
movement" 512 vehicle status information, the vehicle 
mode manger can change the vehicle state to Towed 
504, which indicates the vehicle is being moved while 
not running. Similarly, when the vehicle is cunrently in 
the Towed 504 state, and the vehicle mode manager re- 30 
ceives '*no car movemenr 514 vehicle status informa- 
tion, the vehicle mode manger can change the vehicle 
state to Off 502. However, a towed vehicle may actually 
be being stolen, with out the consent of the owner. 
[0033] In one embodiment, the vehicle mode manger 35 
can receive vehicle status information from a vehicle 
alarm unit. For example, the vehicle alami unit may pro- 
vide the vehicle mode manger with "alarm set" 516 ve- 
hicle status information, which indicates the user has set 
the vehicle alarm, and all vehicle movement when the 40 
alarm is set indicates unlawful vehicle tampering. In this 
embodiment, when the vehicle is currently in the Towed 
502 state, and the vehicle mode manager has received 
"alami set" 516 vehicle status infomiation. the vehicle 
mode manger can change the vehicle state to Stolen 45 
506, which indicates the vehicle is being moved while 
not mnning, and without the owner's consent. Similarly, 
when the vehicle is currently in the Stolen 506 state, and 
the vehicle mode manager receives "alarm disarm" 518 
vehicle status information, the vehicle mode manger so 
can change the vehicle state to Towed 504, generally 
indicating the alanm was triggered accidentally, but the 
owner quickly disarmed the alarm to conrect the mistake. 
Other embodiments could require additional vehicle sta- 
tus infonmation to return the vehicle from the Stolen 506 55 
state, such as a user password. 
[0034] As mentioned previously, application pro- 
grams can react to the cunrent state. For example, re- 



ferring to Figure 4, the stolen carlet 132c may react to 
the stolen 506 vehicle state by sending a message to a 
"car stolen" application service program executing on 
the telematic server. The car stolen application service 
program can then send a page or other message to the 
owner to warn the owner of their current vehicle state. 
[0035] Figure 6 is a flowchart showing a method 600 
for providing vehicle state management, in accordance 
with an embodiment of the present invention. In an initial 
operation 602, preprocess operations are performed. 
Preprocess operations can include vehicle client provi- 
sioning, gathering of user preference information, and 
other preprocess operations that will be apparent to 
those skilled in the art after a careful reading of the 
present disclosure. 

[0036] In operation 604, application programs are 
registered with the vehicle mode manager. As men- 
tioned above, once the vehicle state is defined by the 
vehicle mode manager, interested applications can be 
notified of the vehicle state, and take appropriate action. 
In one embodiment, interested applications are applica- 
tion programs that are registered with the vehicle mode 
manager. Then, whenever the state changes, or when 
queried by a registered application program, the vehicle 
mode manager can provide the vehicle state Infomiation 
to any registered application programs, as described 
subsequently. 

[0037] Vehicle status infomiation is then received, in 
operation 606. The vehicle mode manger receives ve- 
hicle status infomiation from the vehicle sensors, and 
other application programs, and uses the received ve- 
hicle status Information to determine the current vehicle 
state, as described below. In addition, the cun-ent vehi- 
cle state can be set using carlets and/or application 
service programs. For example, the user's preference 
infomnation can be stored on the telematic server. This 
infonmation can Include, for example, the date of the ve- 
hicle's last oil change and the frequency of the vehicle's 
oil changes. Based on this user preference information, 
an application service program executing on the 
telematics server may calculate the date of the next 
scheduled oil change for the vehicle and provide that 
infomiation to the oil service carlet. When the oil service 
carlet is notified of the next oil change, the oil service 
carlet can set the vehicle state, for example, to the 
"check fluids" state. 

[0038] In operation 608, the vehicle mode manager 
determines the vehicle state based on the vehicle status 
information. Continuing with the previous example, the 
oil sensor can provide the vehicle mode manager with 
"low oil" status infomiation. The vehicle mode manager 
then utilizes the low oil status infomnation received from 
the oil sensor, in conjunction with other obtained vehicle 
status infomiation, to calculate the current vehicle state. 
In addition, as described above with reference to Figure 
5, the vehicle mode manager can utilize the current ve- 
hicle state In conjunction with new vehicle status infor- 
mation to detennlne the new vehicle state. 
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(0039] Referring back to Figure 6. the vehicle state is 
provided to registered application programs, in opera- 
tion 610. For example, based on the "low oil" status In- 
fomiation, the vehicle mode manager may set the vehi- 
cle state to "check fluids." and provide the "check fluids" 
state to the registered application programs. In this ex- 
ample, an oil service carlet may react to the new "check 
fluids" state by displaying the oil level to the user, while 
a tow carlet and a stolen cartet may take no action, for 
example, because the services provide by these cartets 
may not be related to the "check fluids" state. 
[0040] Post process operations are perfonned in op- 
eration 61 2. Post process operations can include further 
application program registration and other post process 
operations that wilt be apparent to those skilled In the 
art after a careful reading of the present disclosure. It 
should be noted that vehicle states, or modes, can be 
predefined, such Normal, Towed, and Stolen. Further 
vehicle states, or modes, can be defined after provision- 
ing as needed to react to new software, new hardware, 
and new service subscriptions. 
[0041] As mentioned above, embodiments of the 
present Invention can be implemented in a Java envi- 
ronment using a Java virtual machine. As an overview, 
the Java virtual machine (JVM) is used as an interpreter 
to provide portability to Java applications. In general, de- 
velopers design Java applications as hardware inde- 
pendent software modules, which are executed by Java 
virtual machines. The Java virtual machine layer is de- 
veloped to operate in conjunction with the native oper- 
ating system of the particular hardware on which the 
communications framework 516c is to run. In this man- 
ner, Java applications (e.g., carlets) can be ported from 
one hardware device to another without requiring updat- 
ing of the application code. 

[0042] Unlike most programming languages, in which 
a program is compiled into machine-dependent, execut- 
able program code, Java classes are compiled into ma- 
chine independent byte-code class files which are exe- 
cuted by a machine-dependent virtual machine. The vir- 
tual machine provides a level of abstraction between the 
machine independence of the byte-code classes and 
the machine-dependent instruction set of the underlying 
computer hardware. A class loader is responsible for 
loading the byte-code class files as needed, and an In- 
terpreter or just-in-time compiler provides for the trans- 
formation of byte-codes into machine code. 
[0043] More specifically. Java is a programming lan- 
guage designed to generate applications that can run 
on all hardware platforms, small, medium and large, 
without modification. Developed by Sun, Java has been 
promoted and geared heavily for the Web, both for pub- 
lic Web sites and intranets. Generally, Java programs 
can be called from within HTML documents or launched 
standalone. When a Java program runs from a Web 
page, it is called a "Java applet," and when run on a Web 
server, the application is called a "servlet." 
[0044] Java is an interpreted language. The source 



code of a Java program is compiled into an intemnediate 
language called "bytecode". The bytecode is then con- 
verted (interpreted) into machine code at runtime. Upon 
finding a Java applet, the Web browser invokes a Java 

5 interpreter (Java Virtual Machine), which translates the 
bytecode into machine code and runs it. Thus, Java pro- 
grams are not dependent on any specific hardware and 
will run in any computer with the Java Virtual Machine 
software. On the server side. Java programs can also 

10 be compiled Into machine language for faster perform- 
ance. However a compiled Java program loses hard- 
ware independence as a result. 
[0045] Although the present invention is described 
based on the Java programming language, other pro- 

15 gramming languages may be used to implement the em- 
bodiments of the present invention, such as other object 
oriented programming languages. Object-oriented pro- 
gramming is a method of creating computer programs 
by combining certain fundamental building blocks, and 

20 creating relationships among and between the building 
blocks. The building blocks in object-oriented program- 
ming systems are called "objects." An object is a pro- 
gramming unit that groups together a data structure (in- 
stance variables) and the operations (methods) that can 

25 use or affect that data. Thus, an object consists of data 
and one or more operations or procedures that can be 
perfonmed on that data. The joining of data and opera- 
tions into a unitary building block is called "encapsula- 
tion." 

30 [0046] An object can be instructed to perform one of 
its methods when it receives a "message." A message 
is a command or instruction to the object to execute a 
certain method. It consists of a method selection (name) 
and a plurality of arguments that are sent to an object. 

35 A message tells the receiving object what operations to 
perform. 

[0047] One advantage of object-oriented program- 
ming is the way in which methods are invoked. When a 
message is sent to an object, it is not necessary for the 
40 message to instruct the object how to perform a certain 
method. It is only necessary to request that the object 
execute the method. This greatly simplifies program de- 
velopment. 

[0048] Object-oriented programming languages are 
45 predominantly based on a "class" scheme. A class de- 
fines a type of object that typically includes both instance 
variables and methods for the class. An object class is 
used to create a particular instance of an object. An in- 
stance of an object class includes the variables and 
50 methods defined for the class. Multiple instances of the 
same class can be created from an object class. Each 
instance that is created from the object class is said to 
be of the same type or class. 
[0049] A hierarchy of classes can be defined such that 
55 an object class definition has one or more subclasses. 
A subclass inherits its parent's (and grandparent's etc.) 
definition. Each subclass in the hierarchy may add to or 
modify the behavior specified by its parent class. 
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[0050] To illustrate, an employee object class can In- 
clude "name" and "salary" instance variables and a 
"set.salary" method. Instances of the employee object 
class can be created, or instantiated for each employee 
in an organization. Each object instance is said to be of 5 
type "employee." Each employee object instance in- 
cludes the "name" and "salary" instance variables and 
the "set_salary" method. The values associated with the 
"name" and "salary" variables in each employee object 
instance contain the name and salary of an employee io 
in the organization. A message can be sent to an em- 
ployee's employee object instance to invoke the 
"set_salary" method to modify the employee's salary (i. 
e., the value associated with the "salary" variable in the 
employee's employee object). ^5 
[0051] An object is a generic temn that is used in the 
object-oriented programming environment to refer to a 
module that contains related code and variables. A soft- 
ware application can be written using an object-oriented 
programming language whereby the program's func- 20 
tionallty is implemented using objects. Examples of ob- 
ject-oriented programming languages include C++ as 
well as Java. 

[0052] Furthermore the invention may be practiced 
with other computer system configurations including 25 
hand-held devices, microprocessor systems, micro- 
processor-based or programmable consumer electron- 
ics, minicomputers, mainframe computers and the like. 
The invention may also be practiced in distributing com- 
puting environments where tasks are perfomned by re- 30 
mote processing devices that are linked through a net- 
wori<. 

[0053] With the above embodiments in mind, it should 
be understood that the invention may employ various 
computer-implemented operations involving data 35 
stored in computer systems. These operations are 
those requiring physical manipulation of physical quan- 
tities. Usually, though not necessarily, these quantities 
take the fonm of electrical or magnetic signals capable 
of being stored, transferred, combined, compared, and 40 
othenwise manipulated. Further, the manipulations per- 
fomned are often referred to in terms, such as producing, 
identifying, determining, or comparing. 
[0054] Any of the operations described herein that 
form part of the invention are useful machine operations. 45 
The invention also relates to a device or an apparatus 
for performing these operations. The apparatus may be 
specially constructed for the required purposes, such as 
the TCU discussed above, or it may be a general pur- 
pose computer selectively activated or configured by a so 
computer program stored in the computer. In particular, 
various general purpose machines may be used with 
computer programs written In accordance with the 
teachings herein, or it may be more convenient to con- 
struct a more specialized apparatus to perform the re- 55 
quired operations, 

[0055] The invention can also be embodied as com- 
puter readable code on a computer readable medium. 
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The computer readable medium is any data storage de- 
vice that can store data which can be thereafter be read 
by a computer system. Examples of the computer read- 
able medium include hard drives, network attached stor- 
age (NAS), read-only memory, random-access memory, 
CD-ROMs, CD-Rs, CD-RWs. magnetic tapes, and other 
optical and non-optical data storage devices. The com- 
puter readable medium can also be distributed over a 
network coupled computer systems so that the compu- 
ter readable code is stored and executed in a distributed 
fashion. Further, the computer readable medium can be 
a signal such as an optical, electrical, magnetic, acous- 
tic signal, or electro-magnetic signal. 
[0056] Although the foregoing invention has been de- 
scribed in some detail for purposes of clarity of under- 
standing, It will be apparent that certain changes and 
modifications may be practiced within the scope of the 
appended claims. Accordingly, the present embodi- 
ments are to be considered as illustrative and not re- 
strictive, and the invention is not to be limited to the de- 
tails given herein, but may be modified within the scope 
of the appended claims. 



Claims 

1 . A method for providing vehicle state management, 
comprising the operations of: 

receiving vehicle status information; 

determining a vehicle state based on the vehi- 
cle status infomfiation; and 

providing the vehicle state to an application 
program, wherein the application program re- 
acts to the vehicle state information in a prede- 
fined manner. 

2. A method as recited in claim 1 . further comprising 
the operation of registering the application program, 
wherein registering indicates the application pro- 
gram will be notified of vehicle state changes. 

3. A method as recited In claim 2, wherein the vehicle 
status infonmation is received from a vehicle sensor 
device. 

4. A method as recited In claim 2, wherein the vehicle 
status information is received from an application 
service program. 

5. A method as recited in claim 4, wherein the appli- 
cation service program is executed on a telematic 
server. 

6. A method as recited in claim 4, wherein the appli- 
cation service program is executed on a vehicle cli- 
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ent program. 

7. A method as recited in claim 6. wherein the appli- 
cation service program monitors a vehicle sensor. 

8. A computer program embodied on a computer read- 
able medium for providing vehicle state manage- 
ment, comprising: 

a code segment that receives vehicle status in- 
formation; 

a code segment that determines a vehicle state 
based on the vehicle status information; and 
a code segment that provides the vehicle state 
to an application program, wherein the applica- 
tion program reacts to the vehicle state infor- 
mation in a predefined manner 

9. A computer program as recited in claim 8, further 
comprising a code segment that registers the appli- 
cation program, wherein registering indicates the 
application program will be notified of vehicle state 
changes. 

10. A computer program as recited in claim 9. wherein 
the vehicle status information Is received from a ve- 
hicle sensor device. 

11. A computer program as recited in claim 9. wherein 
the vehicle status infonnation Is received from an 
application service program. 

12. A computer program as recited in claim 11 , wherein 
the application service program is executed on a 
telematic server. 

13. A computer program as recited in claim 11 , wherein 
the application service program Is executed on a ve- 
hicle client program. 

14. A computer program as recited in claim 13. wherein 
the application service program monitors a vehicle 
sensor 



a code module that provides the vehicle state 
to an application program, wherein the applica- 
tion program reacts to the vehicle state infor- 
mation in a predefined manner. 

5 

16. A vehicle mode manager as recited in claim 15, 
wherein the vehicle status information is received 
from a vehicle sensor device. 

10 17. A vehicle mode manager as recited in claim 15, 
wherein the vehicle status information is received 
from an application service program. 

18. A vehicle mode manager as recited in claim 17, 
15 wherein the application service program is execut- 
ed on a telematic server 

19. A vehicle mode manager as recited in claim 17, 
wherein the application service program is execut- 

20 ed on a vehicle client program. 

20. A vehicle mode manager as recited in claim 19, 
wherein the application service program monitors a 
vehicle sensor 

25 

21. Apparatus for providing vehicle state management 
comprising: 

means for receiving vehicle status information; 

30 means for detemiining a vehicle state based on 

the vehicle status Information; and 
means for providing the vehicle state to an ap- 
plication program, wherein the application pro- 
gram reacts to the vehicle state information in 

35 a predefined manner 



40 



15. A vehicle mode manager for providing vehicle state « 
management, comprising: 

a code module that registers an application pro- 
gram with the vehicle mode manager, wherein 
registering indicates the application program 50 
will be notified of vehicle state changes. 

a code module that receives vehicle status in- 
formation; 

55 

a code module that detemiines a vehicle state 
based on both the vehicle status infonnation 
and a cun-ent vehicle state; and 
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